【インフラ？勉強会】#ssmjp 2018/02 参加メモ

はじめに

中山（順）です

本日は、#ssmjp 2018/02というインフラ勉強会に参加しました。

会場はLINE株式会社様のセミナールームでした。

内容についてメモしたものを整理してみました。 ご参考までに。

#ssmjpとは

公式サイトをご覧ください。

#ssmjpとは

togetter

すでにまとめられていました。

https://togetter.com/li/1204042

今日の登壇者

• @wslashさん
  • 「ssmjpで喋ったことのない私が、ssmjpでプレゼンデビューするためのテクニックを話す」
• @ktgohanさん
  • 「あまり他人事ではない『ルート証明書』更新祭顛末記 」(仮)
• @tcshさん
  • 「”属人化”とは何か? 整理してみよう」
• @tomofumiさん
  • LINE Bug Bounty Program の紹介

おことわり

この投稿はセッションを聞きながらメモした内容を整理したものです。
内容や解釈が間違っているかもしれませんので、その際はコメントなどでそっと教えていただけるとうれしいです。

「ssmjpで喋ったことのない私が、ssmjpでプレゼンデビューするためのテクニックを話す」　@wslashさん

資料

自己紹介

• エバンジェリスト
• 年に50回位プレゼンしてる（週1回のペース）
• SoftwareDesignにも寄稿
• プレゼン勉強会も主催

場数をこなすの大事

• 仕事をしてれば、重要なプレゼンをやらなければならないときってありますよね？
• そんなときにスベっていいんですか？
• ssmjpならスベっても大丈夫！
• プレゼンでスベっても死なない

具体的なコツ

資料作り

• いきなりスライドを作らない
  • まずはシナリオを作る
• スライドを作り始めるとき
  • 文字は大きく
  • スライド1枚の情報量は少なく
• 誰が聞いているかを意識する
  • 例えば自己紹介
  • なぜ自分がここにいるのか？
  • 自分の話にどんな価値があるのか？
  • 「それを聞きたいと思っている人は本当にいるのか？」を考えよう

プレゼンテーション

• 観客の方を見て話す
  • PCやスクリーンの方を見て話さない
• 声は大きく
  • 聞こえなければ意味がない
  • 早く喋りすぎない

いきなり重要なプレゼンをすることになったら？

• 練習する
  • たとえ一人でもやる
  • （ちょっとさみしいけど）

まとめ

• いきなり資料を作らない
• 聴衆を意識
• 場数大事

質疑応答

• 一番しんどかったプレゼンは？
  • JANOG
  • ウケなかった
  • 「頑張れ」って言われた

感想

何事においても基礎は本当に大事ですよね。
私自身、プレゼンをする機会は時々ありますが、できていないことが多々あります。。。
簡単なように見えて、慣れてないと意外とできないものなので、みなさんも場数を踏みましょう。

「あまり他人事ではない『ルート証明書』更新祭顛末記 」(仮)　@ktgohanさん

資料

（公開されたら貼ります）

今日の話の背景

Chrome が Symantec の証明書に対する信頼を破棄する予定について

本題

• 今回はルート証明書の話
• SymantecがDigiCertに証明書事業を売却
• 2017年12月、ルート証明書が切り替わった
  • 【続報】【重要】マネージドCA対応に伴うSSLサーバ証明書製品ならびに申請システム等における仕様変更などのご案内
• これ以降に新しく発行される証明書が別の認証局で署名される
  • Managed CA対応リリース後のルート／中間の階層構造について – Part2 (詳細)
• クライアントにこれらのルート証明書が含まれない場合、インストールする必要がある
  • サーバー側だけの問題ではない

具体的な影響事例

• Salesforce
  • 2018 年 1 月と 2 月に実施される Symantec から DigiCert への Salesforce 証明書の変更について
  • 「ただし、一部のミドルウェアソリューションでは、DigiCert ルート証明書、DigiCert 中間証明書、その他の関連する Salesforce の DigiCert 署名証明書を信頼するように設定を更新する必要があります。Salesforce との通信時に特定の証明書を指定する必要があるミドルウェアソリューションを使用している場合は、何らかの対応が必要になると思われます。」

過去の似たような事例

• Github
  • GitHubにおけるSSLの認証エラーを回避するため、EV SSL用ルート証明書を追加する
  • 【注】こちらはブログ執筆にあたりググって見つけた記事です。

影響範囲

実際の影響範囲はご自身で確認をお願いします。

• 比較的最近のクライアントOS
  • 多分大丈夫
  • Windows Updateなどで更新されるはず
• CentOS 6
  • yum updateでOK
• CentOS 5
  • OSでパッケージ管理されてない
  • OpenSSLの更新でOK
• CentOS 4
  • OSでパッケージ管理されてない
  • OpenSSLの更新でも新しいルート証明書が入ってないと思われる
  • 「ソースからビルドした方！それ、その時のままですよ！」
• OpenJDKはバージョンによらず要確認
• クライアントがレガシーだと影響する可能性大

まとめ

• VeriSign Class 3 Public Primary Certification Authority - G5、ありがとう、そしてさようなら！

宣伝

• 技書話人伝
  • 技術書典に落選したので、自分でハコをおさえた
  • 行動力の化身だなって思いました（小並感）

感想

自社サービスやっててこれの影響を受けちゃうと大変ですね。。。
自身でコントロールできない問題へ対処することほど辛いものはない。。。
胃が痛くなりそうです ><

「”属人化”とは何か? 整理してみよう」　@tcshさん

資料

導入

• 今（も）話題の属人化
  • なぜ、属人化はダメなのか
  • その理由は何か整理してみる

アジェンダ

• 属人化とは何なのか？
• 属人化は悪なのか？
• 属人化との特徴
• 属人化とどう向き合うべきか
• まとめ

属人化とは何なのか？

• 属人＝「その人に属すること」
  • もともと法律用語として使われている
  • 良いも悪いもない
• 属人化＝業務などが特定の個人に属すること。強い結びつきがあること。状態、そのように変化すること。　 　　

属人化は悪なのか？

• その状態が望ましいのかどうかによって決まる
  • 望まれた属人化は善
    • 専門性や個性が活きるとき
  • 望まれぬ属人化は悪
    • 定常運用はブラックボックス化が許されない
      • 運用できなくなると事業継続ができない
      • 自分たちの「運用」を知る - 運用設計の本質

属人化との特徴

良い特徴

• 専門性や個性が活きる
• 立ち上がりが早い
• 非再現的な仕事に最適（新規事業の立ち上げなど）

悪い特徴

• 局所的
  • 範囲的なスケーラビリティーが低い
• 非反復的
  • 回数的なスケーラビリティーが低い
• 非再現的
  • 単発的な再現が難しい（でも「失敗は繰り返す」）
  • 育成が難しい
• 揮発的
  • 退職などでノウハウ喪失
  • 「車輪の再発明の恒常化」 > 前に進む感がゼロ
  • 知見が継承されない

属人化とどう向き合うべきか

• 事業のフェズによって向き合い方が異なる
• 属人化すべき領域
  • 不確定性が大きい領域
    • 新規事業の立ち上げなど
  • 専門性や個性を活かして何かを形にする
  • 迅速性、柔軟性に価値がある
• 属人化が継続する不安定領域
  • 属人化したままだと、悪い特徴が顕在化
• 事業継続を可能にする領域
  • 悪い特徴によって発生していた問題を解消
  • 反復性（継続性）、再現性に価値がある
  • 揮発しないことが重要

（オフレコの内容）

（オフレコ話も聞きたい方は、勉強会に足を運びましょう）

まとめ

• 社会は人類による非属人化の成果の上で成り立っている

質疑応答

• Q : 非属人的な業務ばかりだと、個人の能力が下がるのでは？
  • A : 非属人化領域で学ぶ > 能力を属人化領域で活かす > 属人化領域を非属人化する > 繰り返す、とやっていくしかないのでは？
• Q : 一人しかいない場合（フリーランスなど）、どうしたらよい？
  • A : 1年後の自分に引き継げるようにしてはどうか？

感想

いつもどおり非常に論理的でわかりやすいプレゼンでした。
この抽象化能力ほんとすごいです。
質疑の最後で、「1年後の自分に引き継げるように」っで発想も自分にはなかったので、目からウロコとはこのことだなーと思いました。
自分に何らかの仕事が属人化しているということは自身が成長する機会を逸しているとも言える反面、会社の（その時点での）利益は非属人業務から生み出されていることがほとんどだと思うので、私自身も上手くバランスを取っていきたいと思います。

LINE Bug Bounty Program の紹介　@tomofumiさん

資料

自己紹介

• 内製のセキュリティ組織に所属
  • 今は裏方仕事が多い
• 2015年からBug Bounty Programやってる
  • あまり認知されていない。。。
  • 日本からの報告が少ない

アジェンダ

• Bug Bountyとは？
• LINEの取り組み
• 報告事例
• 報告のコツ

Bug Bountyとは？

• 前提
  • 製品やサービスには脆弱性がある
  • テストはするけど、どうしても0にはできない
  • 開発における人的・時間的な制約
• 発見者に報いる仕組み、活動
  • お金などお礼の形は色々
  • 企業の思惑もいろいろ
• 運営パターン
  • 直接運営
    • 企業　ー　報告者
    • サイボウズ（同様の取り組みを行っている先輩企業！）
    • Google, Microsoft, facebook, etc
  • 間接運営
    • 企業　ー　代行事業　ー　報告者
    • 例
      • bugbounty.jp
    • 脆弱性を転売する組織も存在する・・・
  • LINEは直接運営

LINEの取り組み

• ここ（LINE Security Bug Bounty Program）に全部書いてる
  • 受付から報酬の支払いまでの期間はおおよそ2ヶ月くらい
    • 支払いまでの流れはFAQ(Q12. 報奨金が認定されてから、実際に、報奨金を受け取るまでに、どのくらいの期間がかかりますか?)を参照
  • ブログでも書いてる
• 結構貰えるよ！（後述）
• 現金以外にも寄付やノベルティーも用意している
• 功績を公開 　 　

事例

• 値段はリスクの大きさで決まる 　
• 500ドル
  • ユーザ入力を使った正規表現から生じるDOM based XSS
  • テクニカルで非常に（技術的な意味で）おもしろい報告
• 1000ドル
  • インドネシアで提供しているサービスにて
  • ユーザーの位置が特定できてしまう
• 6000ドル
  • OAuthのRedirect処理の設計不備
• 20000ドル
  • Remote Code Execution
  • 詳細は言えないｗ
  • SIP ServerでBuffer Overflow

報告のコツ

ダメな報告

• 「画面バグってる」
• 「X-Frame-Optionsないです」
• Scanner使った結果の報告
  • そもそも規約で禁止されてる行為

良い報告

• どこで、何を見つけたか
• 再現手順がわかりやすい
• PoCやPayload
• リスクが書いてある
• 修正案が書いてある

• これらがあると、早く処理できる

感想

セッションの最後で、「日本では脆弱性の調査を攻撃とみなされる可能性を恐れているのか、文化として成熟していないのか、報告数が少ない。（もちろん常識の範囲内でではあると思いますが）我々は歓迎します！」とおっしゃっていたのがかっこよかったです。
LINEさん、マジLINE

まとめ

ssmjpは最高だぜ！